Companies and other organizations typically maintain information about many different aspects of the organization in order to ensure smooth operation. This organizational information (or organizational data) describes people, resources, applications, and the like, which make up the organization. For example, organizational information descriptive of an employee may include his/her name, job title, salary, telephone number, and/or Internet Protocol (IP) address. Organizational information describing an application may include the application's name and associated services provided by the application. Organizational information describing a resource may describe the resource as a network device (e.g., a printer), the name of the device, and capabilities provided by the network device. Many other types of organizational information may be maintained. In order to be of most use to an organization, the organizational data should be consistent across the organization, readily accessible, and managed such that the data provides maximum benefit to the organization.
The organizational data is often maintained in data storage repositories called directories. Traditional directories are hierarchical. For example, directories in the X.500 standard are hierarchical with different levels, or nodes, for each category of information. The Lightweight Directory Access Protocol (LDAP) is based on the X.500 standard, and also specifies a hierarchical namespace.
In many organizations, many different directories are maintained independently, and may include common data that can become inconsistent across the directories. For example, the human resources (HR) department may have a hierarchical directory containing information about each employee, stored according to job title, while the information technology (IT) department may have a hierarchical directory containing information about each email address, stored with the associated employee name, and according to department. In such an environment, it is relatively easy for common data to become inconsistent among the departments.
To avoid inconsistencies, existing systems, such as metadirectories, attempt to identify common data among the multiple directories, and enforce consistency among the data. Identifying common data is often a difficult task, in part because of the different hierarchies present in the organization. Typically, to identify data that is common among directories, the metadirectory system must search all the various hierarchies to find common data. For example, the system may traverse the HR hierarchy gathering all employee names, and then traverse the IT hierarchy, identifying employee names associated with IT email data. As another example, in order to add a node (e.g., an “IP address” node) under each employee, every hierarchy of every directory must be traversed to find the employee node and insert the IP address node. Traversing, searching, and analyzing these hierarchies is a time-consuming and resource intensive process.
In addition, changing the layout of a hierarchy due to changing business needs, is often difficult or impractical, without a redesign to the metadirectory system. For example, the HR department may change its hierarchy from having a “job title” parent node and “employee name” child node to a hierarchy having a “job title” parent node, a “location” child node, and an “employee name” grandchild node. A metadirectory system that is designed to interface with the first exemplary two-node hierarchy may likely be incompatible with the second exemplary hierarchy because the second hierarchy includes a third node (i.e., “location”) that does not exist in the hierarchy for which the metadirectory was designed.
Conversely, the relatively permanent nature of many hierarchies can also be a drawback, in part because, once a department has deployed a hierarchy, the department is often reluctant to change the hierarchy to more closely match a hierarchy of another department. Organizations' departments typically attempt to design a persistent hierarchy, which will not have to change over time, and which will have a structure and data types most useful to that department. Typically, the hierarchical structure and data types used by one department will not match those of another department.
For example, the HR department may be more interested in maintaining employee information in an employee-centric structure, whereas the IT department may be interested in maintaining network information in a network-centric structure. While the two structures probably contain common data (e.g., employee names, phone numbers, email addresses, etc.), accessing that information requires two different processes (i.e., traversing two different hierarchies). One way to reduce processing might be to impose the HR hierarchy on the IT hierarchy, or vice versa; however, this is not a good solution, because the HR hierarchy is not the most useful structure, and does not contain the most useful data types for the IT department, and vice versa.